下面是一個簡單的BANK系統用Class Diagram呈現的方式

看懂這張系統藍圖：我們的銀行系統是如何設計的？

您可以將眼前這張圖想像成我們銀行系統的**「角色關係圖」或「組織藍圖」**。它幫助我們在動手蓋房子（寫程式）之前，先把每個房間（功能）和它們之間的關係都規劃好。

這張藍圖主要告訴我們三件事：有哪些角色和物件、它們各自有哪些資訊，以及它們之間是如何互動的。

1. 系統中的主要「角色」與「物件」(圖中的方塊)

我們系統裡有幾個核心的角色和物件：

• Admin (管理員): 這是我們系統的基礎管理者，記錄了最基本的個人資料，像是姓名、ID、登入帳號等。
• Bank Users (銀行用戶): 這就是您，我們的客戶。您是一種特殊的使用者，除了有基本的個人資料外，還會有您專屬的「提款卡號碼」。
• Employee (銀行員工): 這是我們的內部員工。他們也是一種使用者，除了基本資料，他們還會有自己的「員工憑證」。
• Transaction (交易紀錄): 這就像一本總帳本，您在銀行做的任何事，比如存錢、領錢，都會在這裡留下一筆紀錄。
• Withdraw (提款), Debit (支出), Credit (存入): 這些是帳本裡記錄的具體事件類型。

2. 角色之間的「關係」(圖中的連線)

這些線條是整張圖的靈魂，它說明了這些角色和物件是如何連結在一起的。

• 「是一種」的關係 (繼承)

  • 您會看到「銀行用戶」和「銀行員工」都有一條箭頭指向「管理員」。
  • 比喻: 這就像在說，「用戶」和「員工」都是一種「管理員」。意思是，不管是您還是我們的員工，都需要有姓名、ID、帳號這些基本資料。我們先把這些共通的東西打包成一個基礎角色(Admin)，然後再為您加上提款卡號，為員工加上員工憑證。這樣設計能確保資料的一致性，也更有效率。

• 「擁有」的關係 (聚合)

  • 「銀行用戶」和「交易紀錄」之間有一條線，線上靠近您這邊有個空心的菱形。
  • 比喻: 這代表您擁有您的交易紀錄。就像您有一個資料夾，裡面裝滿了您所有的銀行收據。一個用戶(您)可以擁有很多張收據(交易紀錄)。即使有一天您不再是我們的客戶，基於法規，我們仍然需要保留您過去的交易收據，它們不會因為您的離開而消失。這就是這個「擁有」關係比較有彈性的地方。

• 「密不可分」的關係 (組合)

  • 「交易紀錄」和「支出紀錄 (Debit)」之間也有一條線，但靠近交易紀錄那邊是個實心的菱形。
  • 比喻: 這代表「支出紀錄」是「交易紀錄」中密不可分的一部分。想像一筆「超市購物」的交易紀錄，它必然包含一個「從帳戶扣款500元」的支出細節。如果這筆交易紀錄被取消了（例如，您辦理了退貨），那麼「扣款500元」這個細節也失去了意義，必須跟著作廢。它們的生命是綁在一起的。

總結來說，這張藍圖告訴我們什麼故事？

當您（Bank User）到提款機領錢時，我們的系統會：

1. 知道是您這個人發起了操作。
2. 建立一筆新的交易紀錄 (Transaction)。
3. 在這筆紀錄中，寫下一個密不可分的「支出 (Debit)」細節，說明錢從您的帳戶離開了。
4. 最後，這筆新的交易紀錄會被放入專屬於您的那個交易紀錄資料夾中。

下一章會來講述UI/UX的幾個測試方式:包函狩野分析、USER STORY等等